-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clients(devtools): tsc type override bug workaround #12933
Conversation
report/README.md
Outdated
However, this breaks tsc declaration creation, specifically needed for the DevTools bundle. It would created something like: | ||
|
||
```js | ||
export type DOM = any; | ||
// ... | ||
export class DOM { ... } | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we fix this in bundle.esm.js
? We could look at the named exports and strip out any typedef {import(...)}
s of the same name. In theory more maintainable than noticing when yarn test-devtools
fails and trying to figure out why.
Looking inside bundle.esm.js
, though, I don't entirely understand why that /** @typedef {import('./dom.js').DOM} DOM */
isn't stripped from the inlined components.js
but it is stripped from the inlined report-renderer.js
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the contents of bundle.esm.js
aren't of concern here, but bundle.esm.d.ts
(which is only generated in the roll script, heh), but your suggestion is still applicable. I believe we might be able to just delete export type DOM = any;
after tsc makes the file and everything will be hunky dory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned bundle.esm.js
because that's what bundle.esm.d.ts
is generated from and I believe why bundle.esm.d.ts
ends up with both a type
and a class
DOM
.
But why bundle.esm.js
has both a typedef
and a class
DOM
in the first place (and not zero DOM
typedefs or many DOM
typedefs), I don't know, so this works for me :) 👍
split off from #12926